feat: UI changes for Authz caching #88
Conversation
There was a problem hiding this comment.
The changes LGTM but just to understand the intention of the changes further, REACT_APP_MAX_AUTHZ_CACHE_EXPIRY_MINUTES is expected to be 'fixed' as the default value 600 / 60 minutes right? i.e. we aren't expecting anyone to be manually toggling that UI env var, are we?
Correct. However the env var is still useful when the UI is not being served by the API (as with local dev). |
|
Thank for the quick review, @deadlycoconuts ! Will be merging this shortly. |
This MR mainly adds a small UI change to warn the users that, when updating permissions for a project, changes may take up to
Xminutes to take effect in the individual components. Since the individual components may set any value for KeyExpirySeconds, a newMaxKeyExpirySecondshas been introduced inapi/pkg/authz/enforcer/enforcer.gowhich is hard-coded to 10 minutes. This means that, components will not be allowed to set key expiry > this value (this will be theX).Illustration
Changes
api/cmd/main.go- Supply UI env varREACT_APP_MAX_AUTHZ_CACHE_EXPIRY_MINUTES. When doing this, whether Authz and caching are enabled on the MLP app does not matter because they could be turned off on MLP but turned on in Turing, Merlin, etc.api/pkg/authz/enforcer/enforcer.go- AddMaxKeyExpirySecondsand a check to ensure that, when initialising the enforcer, the configuredKeyExpirySecondscannot be larger.ui/packages/app/src/config.js- AddMAX_AUTHZ_CACHE_EXPIRY_MINUTESconfigui/packages/app/src/project_setting/user_role/SubmitUserRoleForm.js- Add info in the edit user permissions form